The Internet is a well-known, global network of cooperatively interconnected computer networks. The World Wide Web portion of the Internet is a collection of server computers (referred to as “web sites”) on the Internet, which store Hyper Text Markup Language (HTML) documents that can be publicly accessed by computer users having a connection to the Internet.
Most basically, the Internet comprises a network of computer networks capable of transmitting messages to one another using a common set of operating rules, called communication protocols. Networks comprise addressable devices (computers) connected or “linked” by communication channels. More specifically, the Internet comprises an amalgamation of linked-together “web pages,” accessible by linked web-based users, with the web pages typically presenting information to the user in a graphical fashion.
World Wide Web (“web”) is used herein to refer generally to both (i) a distributed collection of interlinked, user-viewable Hypertext documents (commonly referred to as web documents or web pages) that are accessible via the Internet, and (ii) the client and server software components which provide user access to such documents using standardized Internet protocols. Currently, the primary standard protocol for allowing applications to locate and acquire Web documents is Hyper Text Transfer Protocol (HTTP), and the web pages are encoded using HTML.
However, the terms “web” and “World Wide Web” are intended to encompass future markup languages and transport protocols that may be used in place of (or in addition to) HTML and HTTP.
A user at an individual web-based device (e.g., a workstation) that wishes to access a web page on the Internet typically does so using a graphical user interface software application known as a “web browser.” A variety of commercial web browsers are currently available. Well-known web browsers include Netscape's Navigator® and Microsoft's Internet Explorer®. Web browsers function to initiate connections via the Internet to responsive computers known as “web servers” and to receive information from the web servers that is displayed on the user's workstation. Web browsers accordingly support HTTP, the current underlying communications protocol used by the Internet.
To connect to a desired web site having retrievable information, a user typically enters a network address designated as a Uniform Resource Locator (URL) into the web browser. The URL identifies both the location of the web site and one or more pages of information contained at that web site, the web site being supported by a particular web server. At each URL, text, graphics, or other information may be stored on the web server in a predefined hierarchy. The URL address may be supplied by the user in a variety of ways, to include direct keyboard entry of the address, selection of a previously stored “bookmarked” address, or “clicking” on an appropriate hyper-text link appearing on a web browser control bar or on a displayed web page.
Using the URL, the web browser sends a command in the form of a retrieval request to the web server identified in the URL address. For example, when a URL is entered into a web browser, the web browser sends an HTTP command to the designated web server directing the web server to fetch (download), and then transmit, the requested data (web page) identified by the URL. Information displayed to the user is typically organized into pages that are constructed using a specialized language called HTML or other, similar languages such as XML, etc. The transfer of information between the web browser and the web server is done in the context of a client/server relationship with the web browser being a client of the web server.
Most commonly, networks rely on client/server architectures to perform network operations. A server computer, for instance, communicates with a series of client workstations over a series of coextensive interconnections. The interconnections that connect the server with workstations are implemented using any of a variety of technologies, including various forms of physical medium, such as copper wire (“twisted-pair”), coaxial cable and fiber optic cable, and wireless, electromagnetic transmission either at low-level, such as microwave links and cellular mobile networks, or via satellite.
Typically, “clients” are applications that run on workstations and rely on servers to perform certain operations. For example, an e-mail client is an application that enables a workstation to send and receive e-mail via a local area network (LAN) server and an e-mail server. The term “server” is thus used herein to denote a linked computing device or group of such devices acting as a single unit to provide centralized services to one or more workstations. Clients may rely on servers for any number of functions, including interconnection with other devices, web access, resources (such as database storage of files), and, in some cases, processing power. Web servers respond to a web browser's request by transmitting a web page, or other types of web content. Web content, as used herein, is a set of executable instructions a server serves to a client and which is intended to be executed by the client so as to provide the client with certain functionality.
In order to ensure proper routing of messages between networked devices, messages are first broken up into data packets, each of which receives a destination address according to a consistent protocol, and which are reassembled upon receipt by the target computer. Commonly accepted protocols for use over the Internet are Internet Protocol (IP), which dictates routing information, and Transmission Control Protocol (TCP), according to which messages are broken up into IP packets for transmission, collection, and reassembly.
Given the advances in network technology, a demand for software and systems capable of taking full advantage of these advancements is growing. In this regard, many organizations dependent on information technology are presently attempting to manage complex network environments (e.g., distributed environments) that incorporate diverse hardware, software, applications, networks, and database systems. For example, the microprocessors of devices in a distributed environment may be totally dissimilar from each other. Also, device components of distributed environments often run entirely different operating systems and are entirely independent of each other but strive to cooperate in the sharing of data. The communications protocols used by such distributed environments thus tend to be industry standards, such as Systems Network Architecture (“SNA™”) and TCP/IP. Still, modes of cooperation between networked devices are far from optimal.
Thus, there has been an increasing demand for software and systems capable of fully integrating and optimizing use of these disparate components. Moreover, it would be desirable for these integrated systems, documents, and software to be hardware independent, support multiple users, and be based on a distributed architecture.
One particular situation where hardware independence would be desirable concerns printing via device drivers. A conventional, but inefficient, method of controlling and managing the flow of data to and from diverse input/output (I/O) devices in a distributed environment is through the use of device drivers. Device drivers are software programs that act as an interface between the device and programs that use the device. Generally, each device, such as a particular printer, has a set of specialized commands translatable by a driver for that device. In contrast, most programs access devices by using generic commands. The driver, therefore, accepts generic commands from a program and then translates them into specialized commands for the device.
Generally, peripheral input devices and peripheral output devices, such as printers, faxes, cameras, scanners, etc., interact with operating systems through the use of specific device driver software. The drivers form part of, and interact with, an operating system of a computing system. Certain basic device driver types commonly used with a personal computer, such as drivers for fixed and floppy disk drives, displays, and keyboards, are typically provided as a standard feature within the various operating systems. For many peripheral devices, however, specific drivers are created for each specific type of operating system. These specific drivers typically must be provided with a specific device driver supplied by the manufacturer of that specific input or output device. Thus, a device driver written for one operating system generally cannot be used with another operating system without extensive modifications. New peripheral devices thus require new drivers, which are installed in the operating systems in accordance with procedures specified by the particular operating system.
Universal device drivers have been created in an effort to eliminate or reduce the numerous differing device drivers required by various operating systems in running various peripheral devices. Generally, universal drivers incorporate most of the code necessary for devices in a particular class of devices (such as printers or modems) to communicate with the appropriate operating system components (such as the printer or communications subsystems). Most often, universal drivers are used in combination with mini-drivers, which contain any additional instructions needed to operate a specific device.
One example of a universal driver is disclosed in U.S. Pat. No. 5,265,252 to Rawson et al. (“Rawson”). Rawson describes an intricate, three-part device driver system comprising operating system specific device drivers (“OS specific device drivers”), an operating system specific mapping layer (“OS specific mapping layer”), and a device driver core. The core includes an operating system interface that is generic to different operating systems. An operating system is provided having a device driver interface that is unique to the operating system. The OS mapping layer acts as a conversion program layered between the core and the operating system for converting communications between the device driver interface of the operating system and the generic operating system interface of the core. The device driver core is implemented so as to be portable between different operating systems. The Rawson driver system, however, lacks true platform independence in that the OS specific device drivers are programmed for preexisting, but not newer, peripherals. Additionally, while the device driver core is operating system independent, the OS specific device drivers are not. Thus, the OS specific device drivers would have to be replaced in order to conform to a newly installed operating system.
Another effort to avoid driver dependence was described in U.S. Pat. No. 6,148,346 to Hanson (“Hanson”). Hanson discloses a “dynamic” device driver that allows two-way communication between a computer operating system and a peripheral device. The device driver of Hanson includes two components: an operating system specific device driver portion and an operating system independent device driver portion. The operating system specific device driver portion provides a two-way translation communication layer between the host operating system and the operating system independent device driver portion. The operating system independent device driver portion includes object-oriented code with the device driver information required for operation of the device.
In Hanson, the host computer system assigns each peripheral device a unique address and then retrieves the operating system independent driver, which is remotely or locally stored. The host computer then interprets the retrieved peripheral device driver through the operating system specific device driver portion. The host computer thus controls the peripheral device according to user-initiated commands provided to the peripheral device through the translation layer provided by object-oriented programming. The methods of the Hanson patent, while accommodating various peripheral devices and host operating systems, still must rely on a peripheral driver system required to be located on, and uploaded from, the host computer, the peripheral, or an interlinked server. Further in this regard, the operating system independent driver still must include information regarding peripheral device operation and peripheral specific data object. Thus, Hanson does not completely solve the problems of software application and platform independence in the operation of networked peripherals.
A second area in which the resources of a distributed environment are not efficiently utilized is in the realm of web-based image retrieval, manipulation, and utilization. Presently, systems and services exist which allow web users to extract and share various imaging information over the Internet.
On-line information systems typically include one computer system (the server) that makes information available so that other computer systems (the clients) can access the information. The server manages access to the information, which can be structured as a set of independent on-line services. The server and client communicate via messages conforming to a communication protocol and sent over a communication channel such as a computer network or through a dial-up connection. Typical uses for on-line services include document viewing, electronic commerce, directory lookup, on-line classified advertisements, reference services, electronic bulletin boards, document retrieval, electronic publishing, keyword searching of documents, technical support for products, and directories of on-line services, among others. The service may make the information available free of charge, or for a fee, and may be on publicly accessible or private computer systems.
The user of an on-line service uses a program on the client system to access the information managed by the on-line service. Possible user capabilities include viewing, searching, downloading, printing, and filing the information managed by the server.
U.S. Pat. No. 5,870,552 to Dozier et al. (“Dozier”) teaches a development platform technology for publishing hypermedia documents across wide area networks (WAN). Generally, Dozier addresses the problem of editing hypermedia documents on WAN servers for WAN publishing. Dozier notes that it is not generally possible to “open” multiple WAN documents for editing and to transfer text, images, and URLs among those documents in the seamless fashion as is presently done with typical word processors for local computer documents. Also, Dozier notes that current web authoring tools generally do not provide full WYSIWYG (“What You See Is What You Get”) feedback as to HTML markups and hypermedia links. However, Dozier does not teach a method to effectuate sharing of a device/software independent image in an enterprise resource planning printing environment.
U.S. Pat. No. 5,793,966 to Amstein et al. (“Amstein”) also teaches a client/server system, using a web server that allows for the creation and maintenance of an on-line service using a client system that remotely causes the server to perform operations required in the authoring process. However, Amstein does not address sharing a device/software independent image in an enterprise resource planning printing environment.
U.S. Pat. No. 5,987,480 to Donohue et al. teaches a system and method for delivering documents having dynamic content embedded over the worldwide Internet or a local internet or intranet. More specifically, customized HTTP content is provided based on the identity of the user operating the client computer so that the document is individualized to the user's interests and needs. Donahue does not teach editing, retrieval, and output of a device/software independent image in an enterprise resource planning printing environment.
Accordingly, there is a great need for a new development platform for distributed publishing that overcomes the various limitations described above. This need is especially pronounced and important in view of the rapid expansion of interest in the Internet.
A further area where distributed sharing and accessing of information would be beneficial concerns enterprise resource planning. Enterprise resource planning (ERP) systems are designed to allow a company to manage, monitor and control data captured through isolated business activities. Common ERP systems include SAP R/3, Baan, and People Soft. Typically, database server(s) allow users to access information generated in any segment of the company. In addition, interfaces allow users to configure information obtained from the database or databases. However, sharing user-configured information in an ERP environment is problematic.
ERP systems have interfaces that can be manipulated via custom programming to exchange data. These interface areas are called Application Programming Interfaces, or ERP APIs. The purpose of an ERP API is to allow integration with outside data sources. Each API for each ERP system is individualized and behaves differently. In addition, each ERP system is configured for a specific customer, so the data structures, relevance and properties are unique. Furthermore, customized information reports or forms are often not readily sharable to other users unless printed.
To print, the ERP API communicates with the ERP system to retrieve and format the requested information and then transmit page description language (“PDL”) commands that can be executed by the printer. For example, common PDLs include Postscript or PCL printer languages. Typically, ERP systems provide PDL generation for the desired printer from a program executed on the client.
A large percentage of print jobs is created from reports and forms as generated by ERP APIs. Reports may include financial transaction spreadsheets, accounting information, and budget ledgers. Given the amount of information typically included in these reports, and given the frequency with which they must be accessed and updated, the ability to share and distribute ERP information is extremely important.
However, information extracted from the ERP system may be limited in its ability to be configured. Because APIs are typically customized software, printing functionality is often compromised. In some instances, ERP systems store generated print jobs in queues that sometimes can be accessed at a later time. Also, some ERP systems allow for printing to occur on a printer attached to the client machine. However, the print job is generated on a server and sent to the client machine, which is configured with specialized software to process the job. Irrespective of ERP system type, printing functions are limited in an ERP environment.
Further, many ERP systems do not provide thorough output management and report distribution for the business documents and reports they generate, making it very common for print jobs to be lost, with no additional control over printing. Because ERP systems assume that the delivery of output successfully reaches its intended locations and devices, users may be at risk if delivery of output is unsuccessful. Invoices are one example of a critical output from an ERP system.
The difficulty in printing ERP information has been recognized in the art. Dazel, a subsidiary of Hewlett Packard, Palo Alto, Calif., provides output management systems for managing printing operations in an ERP environment. Output management systems provide increased capabilities and controls that allow users to customize or enhance ERP-generated forms and documents when they are printed. Dazel's output management systems are also designed to help provide reliable, confirmed delivery of printed documents. Additionally, Dazel's output server is able to send output to different devices from one print queue, converting the file format if necessary. However, printing is still often limited to the output devices installed and configured for network and/or ERP access. Also, although Dazel provides an exemplary system for managing printing in an ERP environment, an ERP user would benefit from the computing and output capability of the Internet. Also, if a means to utilize the Internet for ERP printing, tracking, and confirmation were available, the additional expense of an output management system may not be necessary.
In addition, finished projects containing print jobs from different applications cannot be easily integrated prior to printing. Usually, each print job is generated by each application by way of the print driver and sent to a printer, or different printers. This method is inefficient and, furthermore, the disparate print jobs must be manually collated after printing. Although copy/paste functions of operating systems and applications somewhat alleviate this problem, it would be advantageous to assemble a single print job for printing from different applications by selecting files and previous print jobs to comprise the single print job.
Limitations and problems associated with ERP APIs, print queues, print drivers, print job configuration and monitoring largely prevent ERP users from gaining possible benefits of high functional access to peripherals and computing power outside of an ERP/ILAN environment without additional print management systems. In addition, hardware and software independence is desirable, because networks as well as the Internet may comprise diverse computer platforms and systems.
As illustrated by the prior art, it is desirable to provide ERP printing clients with utmost functionality concerning peripherals, computing power, and imaging power available. Therefore, it would be of current interest to provide apparatus and methods for sharing imaging information between web-based services and devices in a distributed environment. More specifically, the present invention relates to apparatus and methods for sharing imaging information between web-based services and devices for users of ERP printing environments.